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RÉSUMÉ. Nous présentons dans cet article un nouveau banc d'essais pour V évaluation des per- 
formances des entrepôts de données. L'emploi de bancs d'essais est profitable pour les utili- 
sateurs, qui peuvent comparer les performances de plusieurs systèmes avant d'investir, mais 
aussi pour les concepteurs d'entrepôts de données, afin d'évaluer l'impact de différents choix 
techniques (indexation, matérialisation de vues...). Les bancs d'essais standards édités par le 
TPC (Transaction Processing Performance CouncilJ répondent au premier de ces besoins, mais 
ne sont pas suffisamment adaptables pour satisfaire le second. C 'est pourquoi nous proposons 
le banc d'essais DWEB (Data Warehouse Engineering Benchmark), qui permet de générer à la 
demande divers entrepôts de données synthétiques, ainsi que les charges ( ensembles de requêtes 
décisionnelles) associées. DWEB est totalement adaptable, mais il demeure facile à mettre en 
œuvre grâce à deux niveaux de paramétrage. Par ailleurs, comme DWEB répond principale- 
ment à des besoins d'évaluation de performance pour l'ingénierie, il est complémentaire plutôt 
que concurrent aux bancs d'essais standards du TPC. Finalement, DWEB est implémenté sous 
la forme d'un logiciel libre écrit en Java qui peut s 'interfacer avec la plupart des systèmes de 
gestion de bases de données relationnels existants. 

ABSTRACT. We présent in this paper a new benchmark for evaluating the performances of data 
warehouses. Benchmarking is useful either to System users for comparing the performances 
of différent Systems, or to System engineers for testing the effect of various design choices. 
While the TPC (Transaction Processing Performance Councilj standard benchmarks address 
the first point, they are not tuneable enough to address the second one. Our Data Warehouse 
Engineering Benchmark (DWEB) allows to generate various ad-hoc synthetic data warehouses 
and workloads. DWEB isfully parameterized. However, two levels of parameterization keep it 
easy to tune. Since DWEB mainly meets engineering benchmarking needs, it is complimentary 
to the TPC standard benchmarks, and not a competitor. Finally, DWEB is implemented as a 
Java free software that can be interfaced with most existing relational database management 
Systems. 

MOTS-CLÉS : Entrepôts de données, requêtes décisionnelles, OLAP, bancs d'essais, évaluation de 
performance, conception d'entrepôts de données. 

KEYWORDS: Data warehouses, décision support queries, OLAP, benchmarking, performance 
évaluation, data warehouse design. 
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1. Introduction 



Evaluer des technologies centrées sur la décision telles que les entrepôts de don- 
nées n'est pas une tâche facile. Bien que des conseils pertinents d'ordre général soient 
disponibles en ligne [PEN 03, GRE 04a], les éléments plus quantitatifs au regard des 
performances de ces systèmes sont rares. 

Dans le contexte des bases de données transactionnelles, des bancs d'essais sont 
traditionnellement utilisés pour évaluer la performance. Ce sont des modèles synthé- 
tiques de bases de données et de charges (opérations à effectuer sur la base), ainsi que 
des ensembles de mesures de performance. Dans le contexte de l'aide à la décision et 
plus précisément lors de la conception et de l'exploitation d'un entrepôt de données, 
de bonnes performances sont encore plus critiques en raison de la nature du modèle 
de données spécifique et de la volumétrie de ces données. L'objectif de cet article est 
de proposer un nouveau banc d'essais pour entrepôts de données. 

Plusieurs objectifs peuvent être visés lors de l'utilisation d'un banc d'essais : 

1) comparer les performances de plusieurs systèmes dans des conditions expéri- 
mentales données (utilisateurs de ces systèmes) ; 

2) évaluer l'impact de différents choix architecturaux ou de techniques d'optimi- 
sation sur les performances d'un système donné (concepteurs d'entrepôts de données). 

Les bancs d'essais proposés par le TPC (Transaction Processing Performance Coun- 
cil), un organisme à but non lucratif qui définit des bancs d'essais standards et publie 
les résultats d'évaluations de performance de façon indépendante, répondent parfaite- 
ment au premier de ces objectifs. Cependant, ils ne sont pas très adaptables : leur seul 
paramètre est un facteur qui définit la taille globale de leur base de données. Néan- 
moins, dans un contexte de développement, il est intéressant de pouvoir tester une 
solution (une stratégie d'indexation automatique, par exemple) sur différentes confi- 
gurations de base de données. Notre objectif est donc de proposer un banc d'essais 
permettant de générer des entrepôts de données synthétiques, ainsi que les charges 
(ensembles de requêtes décisionnelles) associées, pour satisfaire des besoins d'ingé- 
nierie. Nous l'avons baptisé DWEB (Data Warehouse Engineering Benchmark). Il 
faut souligner que DWEB n'est pas concurrent des bancs d'essais décisionnels stan- 
dards édités par le TPC. En effet, nous le considérons plutôt comme complémentaire, 
puisqu'il cible principalement le second objectif mentionné plus haut. 

Cet article est organisé comme suit. Nous étudions tout d'abord l'état de l'art 
concernant les bancs d'essais décisionnels dans la section [2] Nous détaillons ensuite 
la base de données et la charge de DWEB dans les sections [3] et [4] respectivement. 
Nous présentons également brièvement notre implémentation de DWEB dans la sec- 
tion[5] Nous concluons finalement et présentons nos perspectives de recherche dans la 
section [6] 
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2. Bancs d'essais décisionnels existants 



À notre connaissance, il existe très peu de bancs d'essais décisionnels en-dehors 
de ceux du TPC. De plus, les spécifications de ceux que nous avons recensés sont rare- 
ment publiées dans leur intégralité |DEM 95 1. C'est pourquoi nous nous concentrons 
sur les bancs d'essais du TPC dans cette section. 



TPC-D BAL 931 [B HA 96 Tra98) a fait son apparition dans le milieu des années 
90 et forme la base de TPC-H et TPC-R flPOE 001 ITriÔ3âl ITra03bl . qui l'ont désor- 
mais remplacé. TPC-H et TPC-R sont en fait identiques, seul leur mode d'utilisation 
les différencie. TPC-H est conçu pour le requêtage ad-hoc (les requêtes ne sont pas 
connues à l'avance et toute optimisation préalable est interdite), tandis que TPC-R a 
une vocation de reporting (les requêtes sont connues à l'avance et des optimisations 
adéquates sont possibles). TPC-H et TPC-R exploitent le même schéma de base de 
données que TPC-D : un modèle produits-commandes-fournisseurs classique (repré- 
senté par un diagramme de classes UML dans la figure [TJ ; ainsi que la charge de 
TPC-D enrichie de cinq nouvelles requêtes. 



PART 



PARTSUPP 



SUPPLIER 



LINEITEM 



ORDER 1 



TIME 



1..* 











REGION 


1..* 


NATION 


1..* 


CUSTOMER 













Figure 1 - Schéma de la base de données de TPC-D, TPC-H et TPC-R 
Plus précisément, cette charge est constituée de vingt-deux requêtes décisionnelles 
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paramétrées écrites en SQL-92 et numérotées Ql à Q22 et de deux fonctions de ra- 
fraîchissement RF1 et RF2 qui ajoutent et suppriment des n-uplets dans les tables 
ORDER et LINEITEM. Les paramètres des requêtes sont instanciés aléatoirement en 
suivant une loi uniforme. Finalement, le protocole d'exécution de TPC-H ou TPC-R 
est le suivant : 

1) un test de chargement ; 

2) un test de performance (exécuté deux fois), lui même subdivisé en un test de 
puissance et un test de débit. 

Trois mesures principales permettent de décrire les résultats obtenus en termes de 
puissance, de débit et d'une composition de ces deux critères. 

TPC-DS, qui est actuellement en cours de développement |POE 02 1, modélise plus 
clairement un entrepôt de données. Il est le successeur annoncé de TPC-H et TPC-R. 
Le schéma de la base de données de TPC-DS, dont les tables de faits sont représentées 
dans la figure [2] représente les fonctions décisionnelles d'un détaillant sous la forme 
de plusieurs schémas en flocon de neige. Ce modèle comprend également quinze di- 
mensions partagées par les tables de faits. Il s'agit donc d'un schéma en constellation. 



CATALOG RETURNS 



WEB RETURNS 



STORE RETURNS 



CATALOG SALES 



INVENTORY 



WEB SALES 



STORE SALES 



Figure 2 - Schéma de l'entrepôt de données de TPC-DS (tables de faits) 

La charge de TPC-DS est constituée de quatre classes de requêtes : requêtes de 
reporting, requêtes décisionnelles ad-hoc, requêtes interactives d'analyse en ligne 
(OLAP - On-Line Analytical Processing), requêtes d'extraction. Des modèles de re- 
quêtes écrits en SQL-99 (et comprenant donc des extensions OLAP) permettent de 
générer un ensemble d'environ cinq cents requêtes. Ces modèles sont instanciés aléa- 
toirement selon des distributions non-uniformes. Le processus de maintenance de l'en- 
trepôt de données comprend une phase d'ETL (Extract, Transform, Load) complète 
et un traitement spécifique des dimensions. Par exemple, les dimensions historisées 
conservent les anciens n-uplets quand de nouveaux sont ajoutés, tandis que les dimen- 
sions non-historisées ne conservent pas les anciennes données. Finalement, le modèle 
d'exécution de TPC-DS est divisé en quatre étapes : 

1) un test de chargement, 

2) une exécution des requêtes, 
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3) une phase de maintenance des données, 

4) une seconde exécution des requêtes. 

Une seule mesure (de débit) est proposée. Elle prend en compte l'exécution des re- 
quêtes et la phase de maintenance. 

Bien que les bancs d'essais décisionnels du TPC soient adaptables selon la défi- 
nition de Gray |GRA 93], leur schéma est fixe et ils ne sont pas idéaux pour évaluer 
l'impact de choix architecturaux ou de techniques d'optimisation sur les performances 
globales. En effet, un seul paramètre permet de définir leur base de données (Scale 
Factor - SF) en terme de taille (de 1 à 100 000 Go). De plus, leur charge n'est pas 
du tout paramétrable : le nombre de requêtes générées dépend directement de SF 
dans TPC-DS, par exemple. Il s'avère donc intéressant de proposer un banc d'essais 
complémentaire capable de modéliser diverses configurations d'entrepôts de données. 



3. Base de données de DWEB 
3.1. Schéma 

Notre objectif avec DWEB est de pouvoir modéliser différents types d'architec- 
tures d'entrepôts de données |INM 02 KIM 021 au sein d'un environnement ROLAP 
(Relational OLAP) : 

- des schémas en étoile classiques, 

- des schémas en flocon de neige (avec des dimensions hiérarchisées), 

- des schémas en constellation (avec plusieurs tables de faits et des dimensions 
partagées). 

Afin d'atteindre ce but, nous proposons un métamodèle d'entrepôt de données 
(représenté par un diagramme de classes UML dans la figure [3} susceptible d'être 
instancié en ces différents schémas. Nous considérons ce métamodèle comme un in- 
termédiaire entre le métamodèle multidimensionnel du standard CWM {Common Wa- 
rehouse Metamodeï) |Obj03, POO 031 et le modèle final du banc d'essais. Notre mé- 
tamodèle est en fait une instance de celui de CWM, qui pourrait en fait être qualifié de 
méta-métamodèle dans notre contexte. 

Notre métamodèle est relativement simple. La partie supérieure de la figure[3]décrit 
un entrepôt de données (ou un magasin de données si ce dernier est perçu comme 
un petit entrepôt dédié) constitué d'une ou plusieurs tables de faits qui sont chacune 
décrites par plusieurs dimensions. Chaque dimension peut également décrire plusieurs 
tables de faits (dimensions partagées) et peut contenir une ou plusieurs hiérarchies 
composées de différents niveaux. Il est possible de n'avoir qu'un seul niveau, auquel 
cas la dimension n'est pas hiérarchisée. 

Les tables de faits et les niveaux hiérarchiques des dimensions sont tous des tables 
relationnelles, qui sont modélisées dans la partie inférieure de la figure [3] Classique- 
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DATA WAREHOUSE 





1..* 


Description 
1.* 1..* 




FACT TABLE 


DIMENSION 










TABLE 




Child 



Extension 



TUPLE 



Intention 
, . 0..* 



ATTRIBUTE 




Figure 3 - Métaschéma de l'entrepôt de données de DWEB 



ment, une table ou relation est définie en intention par ses attributs et en extension par 
ses n-uplets. A l'intersection d'un attribut et d'un n-uplet donnés se trouve la valeur 
de cet attribut dans ce n-uplet. 



3.2. Paramétrage 

La difficulté principale dans le processus de création d'un schéma d'entrepôt de 
données est le paramétrage de l'instanciation du métaschéma. Nous avons en effet 
pour objectif de satisfaire les quatre critères qui définissent, d'après Gray, un « bon » 
banc d'essais HGRA 931 : 

- pertinence : le banc d'essais doit répondre aux besoins d'ingénierie exprimés 
dans la section[T|; 

- portabilité : le banc d'essais doit être facile à implémenter sur différents sys- 
tèmes ; 

- adaptabilité : il doit être possible d'étudier des bases de données de tailles di- 
verses et d'augmenter l'échelle du banc d'essais ; 

- simplicité : le banc d'essais doit être compréhensible sous peine de ne pas être 
crédible et de demeurer inutilisé. 
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La pertinence et la simplicité forment clairement des objectifs orthogonaux. Intro- 
duire des paramètres en trop petit nombre réduit l'expressivité du modèle, tandis qu'en 
prévoir trop rend le banc d'essais difficile à appréhender par des utilisateurs potentiels. 
En parallèle, la complexité de génération du schéma instancié doit être maîtrisée. Pour 
résoudre ce dilemne, nous tirons partie de l'expérience de la conception du banc d'es- 
sais orienté objets OCB [DAR 00 1 . OCB est générique et capable de simuler tous les 
autres bancs d'essais orientés objets, mais sa mise en œuvre est contrôlée par des pa- 
ramètres trop nombreux, si bien que seule une minorité d'entre eux est utilisée en 
pratique. Nous proposons donc de subdiviser les paramètres en deux sous-ensembles : 

- un sous-ensemble détaillé de paramètres de bas niveau qui permet à un utilisateur 
avancé de contrôler totalement la génération de l'entrepôt de données (tableauQ]) ; 

- une couche supérieure contenant beaucoup moins de paramètres facilement com- 
préhensibles et instanciables (tableau|2]i. Ces paramètres de haut niveau sont plus pré- 
cisément les valeurs moyennes des paramètres de bas niveau. Lors de la génération de 
la base de données, ils sont exploités par des fonctions aléatoires (qui suivent une dis- 
tribution gaussienne) pour fixer la valeur des paramètres de bas niveau. Finalement, 
bien que le nombre de paramètres de bas niveau puisse augmenter de façon signi- 
ficative si le schéma grossit, le nombre de paramètres de haut niveau, lui, demeure 
constant et raisonnable (moins de dix paramètres). 

Les utilisateurs peuvent alors choisir d'initialiser l'ensemble complet de paramètres 
de bas niveau ou bien seulement les paramètres de haut niveau, pour lesquels nous 
proposons des valeurs par défaut correspondant à un schéma en flocon de neige. 



Nom du paramètre 


Signification 


NB_FT 


Nombre de tables de faits 


NB_DIM(f) 


Nombre de dimensions décrivant la table de faits / 


TOT_NB_DIM 


Nombre total de dimensions 


NB_MEAS(f) 


Nombre de mesures dans la table de faits / 


DENSITY(f) 


Densité de la table de faits / 


N B_LEV ELS(d) 


Nombre de niveaux hiérarchiques dans la dimension d 


NB_ATT(d, h) 


Nombre d'attributs dans le niveau hiérarchique h 
de la dimension d 


HHLEVEL_SIZE(d) 


Nombre de n-uplets dans le plus haut niveau hiérarchique 
de la dimension d 


DIM_SFACTOR(d) 


Facteur d'échelle pour la taille des niveaux hiérarchiques 
de la dimension d 



Tableau 1 - Paramètres de bas niveau de l'entrepôt de données de DWEB 



Remarques : 

- Puisque des dimensions partagées sont possibles, 
TOT_NB_DIM < J2?=r FT NB_DIM(i). 
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Nom du paramètre 


Signification 


Valeur déf. 


A VCt N R FT 

/l V V 1 1 V / J I J. 


Wnmnrp trirn/pn np t"Qr\1fic Hp> fciifc 
1>UI11U1C lllUVCll UC LclUlCa U.C ld.lL:> 


1 


AVG_NB_DIM 


Nombre moyen de dimensions 

nar tahlp Hp fait 


5 


AVG_TOT _N B_DI M 


Nombre moyen total de dimensions 


5 


AVG_N B_M EAS 


Nombre moyen de mesures 
dans les tables de faits 


5 


AVG_DEN SITY 


Densité moyenne des tables de faits 


0,6 


AVG_N B_LEV ELS 


Nombre moyen de niveaux hiérarchiques 
dans les dimensions 


3 


AVG_NB_ATT 


Nombre moyen d'attributs 
dans les niveaux hiérarchiques 


5 


AVG_HHLEVEL_SIZE 


Nombre moyen de n-uplets 

dans les plus hauts niveaux hiérarchiques 


10 


DIM_SFACTOR 


Facteur d'échelle de taille moyen 
au sein des niveaux hiérarchiques 


10 



Tableau 2 - Paramètres de haut niveau de l'entrepôt de données de DWEB 



- La cardinalité d'une table de faits est habituellement inférieure ou égale au pro- 
duit des cardinalités de ses dimensions. C'est pourquoi nous introduisons la notion de 
densité. Une densité de 1 indique que toutes les combinaisons possibles des clés pri- 
maires des dimensions sont présentes dans la table de faits. Quand la densité diminue, 
nous éliminons progressivement certaines de ces combinaisons (voir section |33V 

- Au sein d'une dimension, un niveau hiérarchique donné a normalement une car- 
dinalité plus grande que le niveau suivant. Par exemple, dans une hiérachie de type 
villes-régions-pays, le nombre de villes doit être plus grand que le nombre de ré- 
gions, qui doit à son tour être supérieur au nombre de pays. De plus, il existe souvent 
un facteur d'échelle significatif entre ces cardinalités (par exemple, mille villes, cent 
régions, dix pays). C'est pourquoi nous définissons la cardinalité des niveaux hiérar- 
chiques en assignant une cardinalité « de départ » au plus haut niveau de la hiérarchie 
(H H LEV EL_SI Z E). Nous la multiplions ensuite par un facteur d'échelle prédéfini 
(DIM_SFACTOR) pour chaque niveau hiérarchique inférieur. 

3.3. Algorithme de génération 

L'instanciation du métaschéma de DWEB en un schéma d'entrepôt de données 
réel s'effectue en deux étapes : 

1) construction des dimensions et de leurs hiérarchies ; 

2) construction des tables de faits. 

L'algorithme correspondant à ces deux étapes est présenté dans les figures [4] et [5] 
respectivement. Chacune d'entre elles est constituée, pour chaque dimension ou table 
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de fait, de la génération de son intention, puis de son extension. De plus, les hiérarchies 
des dimensions doivent être gérées. Il faut noter qu'elles sont générées en démarrant 
du plus haut niveau hiérarchique. Par exemple, pour notre hiérarchie villes-régions- 
pays, nous construisons le niveau pays en premier, puis le niveau région et enfin le 
niveau ville. Ainsi, les n-uplets d'un niveau hiérarchique donné peuvent référencer 
ceux du niveau supérieur (qui sont déjà créés) à l'aide d'une clé étrangère. 



For 


i = 1 to T0T_NB_DIM do 






previous_ptr = MIL 






size = HHLEVEL_SIZE(i) 






For j = 1 to NB_LEVELS(i) do 






// Intention 






hl = New(Hierarchy_level) 






hl. intention = Primary_key () 






For k = 1 to NB_ATT(i, j) do 






hl. intention = hl. intention U String_descriptor () 




End for 






// Gestion des hiérarchies 






hl . child = previous_ptr 






hl. parent = MIL 






If previous_ptr 7^ NIL then 






previous_ptr .parent = hl 






hl. intention = hl. intention 






U previous_ptr . intention. primary_key // Clé 


étrangère 




End if 






// Extension 






hl. extension = 






For k = 1 to size do 






new_tuple = Integer_primary_key () 






For 1 = 1 to NB_ATT(i, j) do 






new_tuple = new_tuple U Random_string() 






End for 






If previous_ptr 7^ NIL then 






new_tuple = new_tuple U Random_key (previous. 


ptr) 




End if 






hl. extension = hl. extension U new_tuple 






End for 






previous_ptr = hl 






size = size * DIM_SFACTOR(i) 






End for 






dim(i) = hl // Premier (plus bas) niveau de la hiérarchie 


End 


for 





Figure 4 - Algorithme de génération des dimensions 



Nous utilisons trois classes principales de fonctions et une procédure dans ces 
algorithmes. 
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For 


i = 1 to NB_FT do 






// Intention 






ft (i) . intention = 






For j = 1 to NB_DIM(i) do 






j = Random_dimension(f t (i) ) 






ft (i) . intention = ft (i) . intention U ft(i) .dim(j) 


primary_key 




End for 






For j = 1 to NB_MEAS (i) do 






ft (i) . intention = ft (i) . intention U Float_measure () 




End for 






// Extension 






ft (i) . extension = 






For j = 1 to WB_DIM(i) do // Produit cartésien 






ft (i) . extension = ft (i) . extension x f t (i) .dim( j ) 


primary_key 




End for 






to_delete = DENSITY(i) * | f t (i) . extensionl 






For j = 1 to to_delete do 






Random_delete (f t (i) .extension) 






End for 






For j = 1 to | ft (i) . extension | do 






// | ft (i) . extension | est supposée à jour 






For k = 1 to NB_MEAS (i) do 






ft (i) . extension. tuple (j ) .measure (k) = Random_f loat () 




End for 






End for 




End 


for 





Figure 5 - Algorithme de génération des tables de faits 



1) Primary_key (), String_descriptor () et Float_measure() renvoient 
des noms pour les clés primaires, les descripteurs des niveaux hiérarchiques et 
les mesures des tables de faits, respectivement. Ces noms sont étiquetés séquen- 
tiellement et préfixés par le nom de la table (par exemple, DIM1_1_DESCR1, 
DIM1_1_DESCR2...). 

2) Integer_primary_key(), Random_key ( ) , Random_string() et 
Random_f loat () renvoient des entiers séquentiels par rapport à une table don- 
née (aucun doublon n'est permis), des instances aléatoires de la clé primaire de la 
table spécifiée (valeurs aléatoires pour une clé étrangère), des chaînes de caractères 
aléatoires de taille fixe (20 caractères) sélectionnées dans un référentiel préalablement 
construit et préfixées par le nom de l'attribut correspondant, ainsi que des nombres 
aléatoires réels simple précision, respectivement. 

3) Raridom_dimension() renvoie une dimension sélectionnée parmi les dimen- 
sions existantes qui ne décrivent pas déjà la table de faits passée en argument. 

4) Random_delete() efface aléatoirement un n-uplet dans l'extension d'une 
table. 
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A l'exception de la procédure Random_delete(), dans laquelle nous utilisons une 
distribution aléatoire uniforme, nous employons des distributions aléatoires gaussiennes. 

Remarque : La manière dont la densité est gérée dans la figure [5] est clairement 
non-optimale. Nous choisissons de présenter l'algorithme de cette manière afin de le 
rendre plus clair, mais notre implémentation ne crée pas tous les n-uplets du résultat 
du produit cartésien avant d'en effacer certains. Nous générons directement le bon 
nombre de n-uplets en utilisant la densité comme une probabilité de création de chaque 
n-uplet. 



4. Charge de DWEB 

Dans un banc d'essais pour entrepôts de données, la charge peut être subdivisée 

en : 

- une charge de requêtes décisionnelles (principalement des requêtes OLAP) ; 

- le processus d'ETL (chargement et rafraîchissement des données). 

TPC-DS gère ces deux aspects. Puisque la base de données de DWEB compose la 
partie la plus originale de notre travail, nous nous inspirons donc de la définition de 
charge de TPC-DS, tout en exploitant d'autres sources d'informations concernant la 
performance des entrepôts de données |BMC 00 GR E 04bl . Néanmoins, ils nous est 
nécessaire d'adapter les propositions de TPC-DS à la nature variable des entrepôts de 
données de DWEB. De plus, nous voulons satisfaire le critère de simplicité de Gray, 
aussi proposons-nous au final une charge plus simple que celle de TPC-DS. 

Par ailleurs, nous nous concentrons dans un premier temps sur la définition d'un 
modèle de requêtes. La modélisation du processus d'ETL complet est une tâche com- 
plexe sur laquelle nous comptons revenir plus tard. Nous considérons pour l'instant 
que les spécifications actuelles de DWEB permettent une évaluation grossière d'un 
chargement d'entrepôt. En effet, la base de données de DWEB peut être générée sous 
forme de fichiers plats, puis ensuite chargée dans un entrepôt en utilisant les outils 
fournis par le système. 



4.1. Modèle de requêtes 

La charge de DWEB modélise deux types de requêtes : 

- des requêtes purement décisionnelles contenant les opérations OLAP usuelles 
telles que cube, agrégation (roll-up), forage (drill dowri) et projection/sélection (slice 
and dice) ; 

- des requêtes d'extraction. 

Nous définissons notre modèle de requêtes générique (figure |6]l à l'aide d'une 
grammaire qui est un sous-ensemble du standard SQL-99, qui introduit des outils ana- 
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lytiques (indispensables dans un contexte décisionnel) dans les requêtes relationnelles. 
Cela nous permet de générer des requêtes SQL analytiques dynamiquement. 



Query : :- 




Select 
From 


![< Attribute Clause > | <Aggregate Clause > 
| [<Attribute Clause>, <Aggregate Clause>]] 
!<Table Clause> [<Where Clause> 
|| [<Group by Clause> *<Having Clause>]] 


Attribute Clause : :- 

A (Tfrri^fTQtP 1 PIciiicp ■ 
rt.ggICgd.LC l_.ld.LlaC . . 


Attribute Name [[, <Attribute Clause>] | _L] 

1 d nn l'sl fJSïfs? ti II Vlf*t 1 f\ M A/ /l 1 37 £> 1 A tfvihllit& A/ flYVI & 1 1 A C A / 7/7 C 1 

\ cXtlltï r liftC LlUll lyLU Ht, \fi.llr lUitit, 1\ Lltftt, ) J ^rVa /1/itiJj 

[[, <Aggregate Clause>] ±] 


Table Clause : :- 


Table Name [[, <Table Clause>] |_L] 


Where Clause : :- 

Condition Clause : :- 

Operand Clause : :- 
Join Clause : :- 


Where ![<Condition Clause> | <Join Clause> 
| [<Condition Clause> And <Join Clause>]] 

\[Attribute Name <Comparison Operator> <Operand Clause>] 
[[<Logical Operator> <Condition Clause>] | _L] 
[Attribute Name \ Attribute Value \ Attribute Value List] 

\\Attribute Name i = Attribute Name j] [[And <Join Clause>] |_L] 


Group by Clause : :- 
Having Clause : :- 


Group by [Cube | Rollup] <Attribute Clause> 
[Alias Aggregate Function Name (Attribute Name)] 
<Comparison Operator> [Attribute Value \ Attribute Value List] 



Figure 6 - Modèle de requêtes de DWEB 



Définissons la sémantique de la terminologie employée dans la figure [6] 

- Les crochets [ et ] sont des délimiteurs. 

- !<A> : A est requis. 

- *<A> : A est optionnel. 

- <A || B> : AouB. 

- <A | B> : A ou exclusif B. 

- _L : clause vide. 

- Les éléments du langage SQL sont indiqués en gras. 
4.2. Paramétrage 

Comme les paramètres de la base de données de DWEB (section 13. 2\ , ceux qui 
définissent sa charge (tableau |3j ont été conçus pour répondre au critère de simplicité 
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de Gray. Ils déterminent la manière dont le modèle de requêtes de la figure [6] s'ins- 
tancie. Nous ne disposons ici que d'un nombre limité de paramètres de haut niveau 
(huit paramètres, puisque PROB_EXTRACT et PROB_ROLLUP sont calcu- 
lés à partir de PROBjOLAP et PROB_CUBE, respectivement). Il n'est en effet 
pas envisageable d'entrer plus dans le détail si la taille de la charge atteint cinq cents 
requêtes comme c'est le cas dans TPC-DS, par exemple. 



Nom du paramètre 


Signification 


Valeur par défaut 


NB_Q 


Nombre approximatif de requêtes 
dans la charge 


100 


AVG_NB_ATT 


Nombre moyen d'attributs sélectionnés 
dans une requête 


5 


AVG_NB_RESTR 


Nombre moyen de restrictions 
dans une requête 


3 


PROBjOLAP 


Probabilité que le type 
de requête soit OLAP 


0,9 


PROB_EXTRACT 


Probabilité que la requête 


1 




soit une requête d'extraction 


-PROBjOLAP 


AVG_NB_AGGREG 


Nombre moyen d'agrégations 
dans une requête OLAP 


3 


PROBJOUBE 


Probabilité qu'une requête OLAP 
utilise l'opérateur Cube 


0,3 


PROB_ROLLUP 


Probabilité qu'une requête OLAP 


1 




utilise l'opérateur Rollup 


-PROBJOUBE 


PROB_HAVING 


Probabilité qu'une requête OLAP 
contienne une clause Having 


0,2 


AVG_NB_DD 


Nombre moyen de forages (drill clowns) 
après une requête OLAP 


3 



Tableau 3 - Paramètres de la charge de DWEB 



Remarque : NB_Q n'est qu'une approximation du nombre de requêtes parce que 
le nombre de forages (drill downs) effectués après une requête OLAP est variable. 
Nous ne pouvons donc arrêter le processus de génération que lorsque nous avons ef- 
fectivement produit au moins NBjQ requêtes. 

4.3. Algorithme de génération 

L'algorithme de génération de la charge de DWEB est présenté dans les figures [7] 
et [ÏÏ] Son objectif est de générer un ensemble de requêtes SQL-99 qui puisse être 
directement exécuté sur l'entrepôt de données synthétique défini à la section [3] Il est 
subdivisé en deux étapes : 

1) génération d'une requête initiale qui peut être soit une requête OLAP, soit une 
requête d'extraction ; 
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2) si la requête initiale était de type OLAP, exécution d'un certain nombre de fo- 
rages basés sur cette première requête. Plus précisément, à chaque fois qu'un nouveau 
forage est exécuté, un attribut d'un niveau inférieur de la hiérarchie d'une dimension 
est ajouté à la clause Attribute Clause de la requête précédente. 

La première étape est elle-même subdivisée en trois sous-étapes : 

1) les clauses Select, From et Where d'une requête sont générées simultané- 
ment en sélectionnant aléatoirement une table de faits et des dimensions (y compris 
un niveau hiérarchique dans chacune de ces dimensions) ; 

2) la clause Where est complétée par des conditions supplémentaires ; 

3) finalement, le choix du type de requête est effectué (requête OLAP ou requête 
d'extraction). Dans le second cas, la requête est terminée. Dans le premier, des fonc- 
tions d'agrégat appliquées à des mesures de la table de faits sont ajoutées à la requête, 
ainsi qu'une clause Group by pouvant inclure les opérateurs Cube ou Rollup. Il est 
également possible d'ajouter une clause Having. La fonction d'agrégat que nous ap- 
pliquons sur les mesures est toujours une somme car c'est l'opération la plus courantes 
dans les cubes. De plus, les autres fonctions d'agrégat ont des complexités similaires 
en temps de calcul. Elles n'apporteraient donc pas plus d'information dans le cadre 
d'une étude de performance. 

Nous utilisons trois classes de fonctions et une procédure dans cet algorithme. 

1) Random_string() et Random_f loat () sont les mêmes fonctions que celles 
décrites dans la section 13.31 Cependant, nous introduisons ici la possibilité pour 
Random_f loat () d'utiliser une distribution aléatoire soit uniforme, soit gaussienne. 
Cela dépend des paramètres passés à la fonction : distribution uniforme pour un in- 
tervalle de valeurs, distribution gaussienne pour une valeur moyenne. Finalement, 
nous introduisons la fonction Random_int() qui se comporte exactement comme 
Random_f loat () , mais qui retourne des valeurs entières. 

2) Random_FT() et Random_dimension() permettent de sélectionner une table 
de faits et une dimension qui décrit une table de faits donnée, respectivement. Elles 
utilisent toutes deux une distribution aléatoire gaussienne. Random_dimension() est 
également déjà décrite dans la section 1331 

3) Random_ attribute () et Random_measure () ont des comportements très si- 
milaires. Elles retournent un attribut ou une mesure, respectivement, appartenant à 
l'intention d'une table ou à une liste d'attributs. Elles utilisent toutes deux une distri- 
bution aléatoire gaussienne. 

4) Gen_query () est la procédure qui est chargée de générer effectivement le code 
SQL-99 des requêtes de la charge, d'après les paramètres nécessaires pour instancier 
notre modèle de requêtes. 
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n = 




While n < NB_Q do 




// Etape 1 : Requête initiale 




// Etape 1.2 : Clauses Select, From et Where 




i = Random_FT() // Sélection de la table de faits 




attribute_list = 




table_list = ft(i) 




condition_list = 




For k = 1 to Random_int (AVG_NB_ATT) do 




j = Random_dimension(f t (i) ) // Sélection d'une dimension 


1 = Random_int (1 , ft(i) .dim(j) .nb_levels) 




// Positionnement au niveau hiérarchique 1 




hl = ft(i).dim(j) // Niveau hiérarchique courant 




m = 1 // Compteur de niveau 




fk = ft (i) . intention. primary_key . élément (j ) 




// (Cette clé étrangère correspond à ft(i).dim(j) 


.primary_key) 


While m < 1 and hl.child ^ NIL do 




// Construction de la jointure 




table_list = table_list U hl 




condition_list = condition_list 




U (fk = hl . intention. primary_key) 




/ / Niveau suivant 




fk = hl . intention. foreign_key 




m = m + 1 




hl = hl.child 




End while 




attribute_list = attribute_list 




U Random_attribute (hl . intention) 




End for 




// Etape 1.2 : Compléter la clause Where 




For k = 1 to Random_int(AVG_NB_RESTR) do 




condition_list = condition_list 




U (Random_attribute (attribute_list) = Random_s 


tringO) 


End for 




// Etape 1.3 : Sélection requête OLAP ou requête d'extraction 


pl = Random_f loat (0, 1) 




If pl < PR0B_0LAP then // Requête OLAP 




// Agrégat 




aggregate_list = 




For k = 1 to Random_int (AVG_NB_AGGREG) do 




aggregate_list = aggregate_list 




U Random_measure (ft (i) . intention) 




End for 

../.. 





Figure 7 - Algorithme de génération de la charge - Partie 1 
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// Clause Group by 
group_by_list = attribute_list 
p2 = Random_float(0,l) 
If p2 < PR0B_CUBE then 

group_by_operator = CUBE 
Else 

group_by_operator = ROLLUP 
End if 

// Clause Having 

p3 = Random_float(0,l) 

If p3 < PR0B_HAVING then 

having_clause = (Random_attribute (aggregate_list) , >, 
Random_f loat () ) 

Else 

having_clause = 
End if 

Else // Requête d'extraction 

group_by_list = 

group_by_operator = 

having_clause = 
End if 

// Génération de la requête SQL 

Gen_query(attribute_list, aggregate_list , table_list, 
condition_list , group_by_list , group_by_operator , 
having_clause) 

n = n + 1 

// Etape 2 : Eventuelles requêtes DRILL DOWW 
If pl < PR0B_0LAP then 
k = 

While k < Random_int (AVG_NB_DD) and hl. parent / MIL do 
k = k +1 
hl = hl . parent 

att = Random_attribute (hl . intention) 
attribute_list = attribute_list U att 
group_by_list = group_by_list U att 

Gen_query (attribute_list , aggregate_list , table_list, 
condition_list , group_by_list , group_by_operator , 
having_clause) 
End while 
n = n + k 
End if 
End while 



Figure 8 - Algorithme de génération de la charge - Partie 2 
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5. Implémentation de DWEB 

DWEB est implémenté sous la forme d'une application Java. Nous avons choisi 
le langage Java pour satisfaire le critère de portabilité de Gray. La version actuelle de 
notre prototype permet de générer des schémas en flocon de neige. Les schémas en 
constellation ne sont pas encore implémentés. Par ailleurs, comme les paramètres de 
DWEB peuvent sembler abstraits, notre prototype propose une estimation de la taille 
de l'entrepôt généré en méga-octets une fois que les paramètres sont fixés et avant la 
génération de la base de données. Ainsi, les utilisateurs peuvent ajuster les paramètres 
pour obtenir le type d'entrepôt de données qu'ils souhaitent. Notre prototype peut être 
interfacé à la plupart des systèmes de gestion de bases de données relationnels grâce 
à JDBC. La charge de DWEB est également en cours d'impléméntation. Seule une 
charge simplifiée est disponible actuellement. 

Par ailleurs, comme nous utilisons de nombreuses fonctions aléatoires, nous pen- 
sons aussi introduire dans notre prototype un générateur pseudo-aléatoire plus perfor- 
mant que ceux fournis en standard, comme celui proposé par Lewis et Payne [ L EW 731 , 
qui est un des meilleurs grâce à sa très grande période. 

Finalement, bien que notre application soit en perpétuelle évolution, sa dernière 
version est en permanence disponible en ligne [DUC 04 1. 

6. Conclusion et perspectives 

Nous avons présenté dans cet article les spécifications complètes d'un nouveau 
banc d'essais pour entrepôts de données baptisé DWEB. La caractéristique principale 
de DWEB est qu'il permet de générer des entrepôts de données synthétiques variés, 
ainsi que les charges (ensemble de requêtes) associées. Les schémas d'entrepôt clas- 
siques, comme les modèles en étoile, en flocon de neige et en constellation sont en ef- 
fet supportés. Nous considérons DWEB comme un banc d'essais d'ingénierie destiné 
aux concepteurs d'entrepôts de données et de systèmes. En cela, il n'est pas concur- 
rent du banc d'essais TPC-DS (actuellement en cours de développement), qui est plus 
à destination des utilisateurs finaux, pour des évaluations de performances « pures ». 
Il faut toutefois remarquer que le schéma d'entrepôt de données de TPC-DS peut être 
modélisé à l'aide de DWEB. Cependant, la charge de DWEB n'est actuellement pas 
aussi élaborée que celle de TPC-DS. Finalement, nous avons pour objectif de fournir 
dans cet article les spécifications les plus complètes possibles de DWEB, de manière à 
ce que notre banc d'essais puisse être implémenté facilement par d'autres chercheurs 
et/ou concepteurs d'entrepôts de données. 

Nos travaux futurs dans ce domaine sont divisés en quatre axes. Premièrement, 
il nous est nécessaire de terminer l' implémentation de DWEB (charge, schémas en 
constellation avec hiérarchies partagées, génération de fichier plats et chargement dans 
une base de données, tests divers...). Ce travail est actuellement en cours. Des expé- 
riences avec DWEB devraient également nous permettre de proposer un meilleur pa- 
ramétrage par défaut de notre banc d'essais. Nous encourageons également d'autres 
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chercheurs et/ou concepteurs d'entrepôts de données à publier les résultats de leurs 
propres expériences avec DWEB. 

Deuxièmement, ils nous faut tester la pertinence (d'après la définition de Gray) 
de notre banc d'essais pour l'évaluation de performance des entrepôts de données 
dans un contexte d'ingénierie. Afin d'atteindre cet objectif, nous pensons comparer 
l'efficacité de plusieurs techniques de sélection automatique d'index et de vues maté- 
rialisées (dont certaines de nos propositions, ce qui a constitué une des motivations de 
la conception de DWEB à l'origine). 

Troisièmement, nous comptons progressivement améliorer DWEB. Par exemple, 
dans cet article, nous supposons implicitement que nous pouvons réutiliser ou faci- 
lement adapter le protocole d'exécution et les mesures de performance de TPC-DS. 
Une réflexion plus élaborée à propos de ces sujets pourrait être intéressante. Il sera 
également important d'inclure complètement le processus d'ETL dans notre charge. 
Plusieurs travaux existants [LAB 98] pourraient d'ailleurs nous y aider. Finalement, 
il serait intéressant de rendre notre charge plus dynamique, comme cela a été fait 
dans la plate-forme d'évaluation de performance DoEF |HE 03, IHE 04l . Bien que la 
dynamicité ne soit peut-être pas un facteur pertinent dans une charge décisionnelle, 
cette possibilité pourrait néanmoins être explorée. Pour finir, puisque nous travaillons 
par ailleurs sur l'entreposage de données complexes (multiformats, multistructures, 
multisources, multimodales et/ou multiversions), nous envisageons également une ex- 
tension « données complexes » pour DWEB à long terme. 

Finalement, DWEB pourrait évoluer pour devenir capable de proposer automati- 
quement des configurations d'entrepôts de données et des charges afin d'évaluer les 
performances d'une architecture d'entrepôt donnée ou d'une technique de sélection 
d'index ou de vue matérialisée. DWEB pourrait alors capitaliser la connaissance ac- 
quise au cours de diverses expériences et la réutiliser pour proposer de nouvelle confi- 
gurations, plus pertinentes. 
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